Yes Treasury Withdrawals Committed

IO & Ensurable Systems: Cardano Maintenance Initiative

2026-05-24

Summary

RCADA votes YES on the IO & Ensurable Systems: Cardano Maintenance Initiative Treasury Withdrawal proposal.

RCADA supports this proposal because Cardano’s core maintenance is essential infrastructure. Every feature, upgrade, DApp, wallet, stake pool, governance process, and future scaling initiative depends on a stable, secure, well-maintained base layer.

The proposal requests ₳62,134,630 for continuous maintenance and operational support from Q3 2026 through Q1 2027, covering node bug fixing, DevOps, CI/CD, disaster recovery, monitoring, documentation, open-source support, performance optimisation, QA, release management, incident response, Plutus Core, DB-Sync, guardrails scripts, APIs, CLI tools, and related components.

RCADA recognises IO’s strong maintenance track record and the continuity risk of interrupting core maintenance funding. However, this YES vote is not a blank cheque. RCADA expects future maintenance funding to become more transparent, measurable, modular where practical, and explicitly oriented toward distributed multi-party stewardship.

Key Considerations

  • Core maintenance is essential to Cardano’s security, reliability, release quality, and operational continuity.
  • IO has carried a significant share of Cardano’s maintenance responsibility to date and has demonstrated deep protocol expertise.
  • There is no practical or sensible path to abruptly remove IO’s expertise from the maintenance envelope without creating continuity risk.
  • RCADA does not believe the long-term goal should be to replace IO with another single dominant provider.
  • Cardano should instead foster progressive multi-party stewardship across capable ecosystem contributors, independent engineering groups, SPOs, auditors, open-source organisations, alternative client teams, and neutral coordination structures.
  • Ensurable Systems’ involvement is positive insofar as it points toward broader shared infrastructure stewardship.
  • The Treasury ask is large and requires stronger future transparency, cost attribution, measurable reporting, and independent assurance.
  • Documentation should be treated as a serious maintenance deliverable, especially around network architecture, node setup, configuration, operational practices, and implementation-independent specifications.
  • RCADA recognises community concerns around proposal size, budget granularity, potential overlap with other IO-led initiatives, and concentration of Treasury funding.

What this action does

This Treasury Withdrawal proposal funds continuous core maintenance and operational support for Cardano from Q3 2026 through Q1 2027.

The proposal covers nine broad functional areas: node bug fixing and architecture, DevOps and infrastructure, monitoring, documentation, open-source support, performance, quality assurance, release/support/security, and component maintenance.

The proposal includes work on disaster recovery, CI/CD infrastructure, mainnet and mempool monitoring, the Cardano Blueprint, performance benchmarking, E2E testing, release sign-off, L1/L2/L3 incident management, Plutus Core, DB-Sync, Cardano API, Cardano CLI, guardrails scripts, and related components.

Funds are to be administered through Intersect-managed Treasury smart contracts with milestone-based controls, third-party assurance, oversight mechanisms, public auditability, and refund conditions for unused funds.

Analysis Findings

Constitutional / Guardrails Assessment

  • ✔ The proposal specifies a clear Treasury ask of ₳62,134,630.
  • ✔ The proposal identifies the intended delivery period as Q3 2026 through Q1 2027.
  • ✔ The proposal describes the purpose of the withdrawal: continuous maintenance and operational support for Cardano’s core infrastructure.
  • ✔ The proposal includes budget categories covering development, infrastructure, security and audits, legal and compliance, engagement and ecosystem support, operations and delivery, governance, and other costs.
  • ✔ The proposal discloses prior Treasury receipts for IO and affiliated entities.
  • ✔ The proposal states that it does not breach the applicable 350M ADA Net Change Limit at the time of submission.
  • ✔ The proposal includes refund conditions for unused funds or reduced scope.
  • ✔ Funds are to be administered via Intersect-managed Treasury smart contracts, with third-party assurance and oversight mechanisms.
  • ✔ The proposal states that Treasury smart contract funds will not be staked with an SPO and will be delegated to the auto-abstain predefined DRep.
  • ⚠ The large Treasury ask requires a high standard of public accountability.
  • ⚠ Public cost attribution could be clearer at the line-item, staffing, and workstream levels.
  • ⚠ Continuous maintenance work is harder to assess than discrete milestone-based feature delivery and requires stronger measurable reporting.
  • ⚠ Future proposals should more clearly demonstrate how recurring maintenance funding supports distributed stewardship and avoids single-provider dependency.

Assessment: Conditional Pass

Process & Governance Quality

  • ✔ The proposal addresses an essential and non-discretionary infrastructure need.
  • ✔ The proposal includes improved Treasury administration mechanisms compared with earlier informal funding models.
  • ✔ Milestone controls, third-party assurance, Intersect administration, refund provisions, and public auditability are positive governance features.
  • ✔ The collaboration with Ensurable Systems is a constructive step toward wider infrastructure participation.
  • ⚠ The proposal groups a broad maintenance envelope into one large Treasury request.
  • ⚠ The public budget relies heavily on broad cost categories rather than granular FTE, staffing, or workstream-level cost attribution.
  • ⚠ Some concerns remain around possible overlap with other IO-led initiatives.
  • ⚠ Future maintenance proposals should be more modular where practical and provide clearer public measurement of outputs and service levels.

Assessment: Mixed to Strong, with transparency improvements required

Impact & Risk Analysis

  • Ecosystem benefit: High
  • Operational importance: High
  • Security and reliability importance: High
  • Execution credibility: High
  • Treasury risk: Medium to High
  • Concentration risk: Medium
  • Transparency risk: Medium
  • Continuity risk if rejected: Medium to High

RCADA believes the risk of interrupting or destabilising core maintenance outweighs the concerns that would otherwise justify a No vote. However, the proposal size and recurring nature of the work mean that future maintenance funding must improve in cost transparency, measurement, modularity, and distributed participation.

Assessment: High value / Medium-to-High governance scrutiny

Ratings (Decision Support Only)

Dimension Score (1–5)
Constitutional clarity 4
Governance quality 3
Execution credibility 4
Ecosystem value 5
Risk balance 4
Overall score 🟢 80% — Support with strong accountability signal

RCADA Rationale

RCADA votes YES on the IO & Ensurable Systems: Cardano Maintenance Initiative Treasury Withdrawal proposal.

We support this proposal because Cardano’s core maintenance is essential infrastructure. Every feature, upgrade, DApp, wallet, stake pool, governance process, and future scaling initiative depends on a stable, secure, well-maintained base layer. Maintenance is not a discretionary luxury; it is the operational foundation that allows Cardano to remain reliable as a production blockchain.

RCADA recognises that IO has carried a significant share of Cardano’s core maintenance responsibility to date and has done so with a strong overall record. Cardano’s stability, release discipline, security posture, and continued protocol evolution have benefited from IO’s institutional knowledge and technical depth. At this stage, there is no practical or sensible path to simply remove that expertise from the maintenance envelope without creating unnecessary continuity risk.

However, RCADA does not believe the long-term objective should be to replace IO with another single dominant maintenance provider. Cardano should avoid recreating single-provider dependency, whether that provider is IO or any future organisation. The healthier path is progressive multi-party stewardship, where IO continues to contribute its deep protocol expertise while more responsibilities are opened, where practical and safe, to capable ecosystem contributors, independent engineering groups, alternative client teams, SPOs, auditors, open-source organisations, and neutral coordination structures.

We therefore view the collaboration with Ensurable Systems as a positive step, not because it replaces IO, but because it points toward a broader and more resilient maintenance model. Cardano’s long-term infrastructure health will be strengthened when knowledge, responsibility, tooling, monitoring, documentation, and operational capability are distributed across a wider bench of competent contributors.

The proposal covers a wide and important maintenance envelope, including node bug fixing, DevOps and CI/CD infrastructure, disaster recovery, mainnet and mempool monitoring, documentation, open-source support, performance optimisation, QA, release management, incident response, Plutus Core, DB-Sync, guardrails scripts, APIs, CLI tools, and related components. These are not glamorous workstreams, but they are critical to keeping Cardano safe, usable, and dependable.

RCADA also sees value in the proposal’s focus on the Cardano Blueprint and implementation-independent documentation. In our view, documentation should be treated as a serious maintenance deliverable, not a secondary activity. Cardano’s technical documentation remains fragmented across repositories, specifications, guides, and community-maintained resources. We would welcome a more coherent and accessible documentation layer covering network architecture, node setup, configuration, operational practices, core technologies, and implementation-independent specifications. Better documentation would benefit SPOs, developers, auditors, alternative client teams, and new contributors.

That said, our YES vote should not be read as a blank cheque.

This proposal requests ₳62,134,630, which is a substantial Treasury allocation. Large recurring maintenance budgets must meet a high standard of public transparency, cost justification, measurable delivery, and independent assurance. While the proposal includes budget categories, refund provisions, smart-contract administration, third-party assurance, prior Treasury receipt disclosure, and Net Change Limit compliance, RCADA agrees with the broader community concern that future maintenance proposals should provide clearer line-item detail, staffing assumptions, workstream-level cost attribution, and measurable public reporting.

We are also wary of Treasury-funded maintenance becoming an opaque mechanism for underwriting ongoing employment under a broad maintenance umbrella. Maintenance work is essential, and the people performing it should be fairly compensated, but recurring public funding must remain tied to clear outputs, visible service levels, delivery evidence, and ecosystem benefit. The community should be able to understand not only that maintenance is needed, but what is being maintained, by whom, at what cost, and with what measurable results.

RCADA would therefore like to see future maintenance reporting include clearer evidence around uptime, incident response, release cadence, security reviews, unresolved critical issues, test coverage, performance benchmarks, documentation progress, open-source contribution handling, and progress toward broader multi-party participation. Continuous maintenance does not remove the need for measurable accountability.

We also recognise the concerns raised by other DReps and community members around proposal size, budget granularity, potential overlap with other IO-led initiatives, and concentration of Treasury funding. The Cardano Foundation’s abstention, for example, highlights legitimate questions about financial detail, potential duplication, quantifiable deliverables, and the need for a more modular and node-agnostic maintenance approach. These concerns are valid and should influence how future maintenance proposals are structured.

Nevertheless, RCADA believes that rejecting this proposal outright would create more risk than benefit at this stage. Cardano needs uninterrupted maintenance coverage. The operational scope is real, the expertise required is significant, and the network should not be placed in a position where essential maintenance becomes uncertain while alternative structures are still maturing.

For these reasons, RCADA votes YES, while strongly emphasising that future maintenance funding should become more transparent, more measurable, more modular where practical, and more explicitly oriented toward distributed stewardship. Cardano should continue funding the maintenance it depends on, but it should also use that funding to widen participation, improve documentation, strengthen public accountability, and reduce long-term dependency on any single organisation.